This invention relates to electronic communication systems, and more particularly to mobile electronic communication systems.
Data communication networks can be classified according to a number of criteria, including for example the “reachability” of the hosts connected to a network. A “host” is generally a computer, such as a server, that provides client stations with access to files and printers as shared resources on the network, and a host is “reachable” if a device can communicate with the host. If a first host is reachable from any other host connected to any other data network, such as the Internet for example, then the data network to which the first host is connected is usually said to be a “public” network, or an “open” network, or even just the “Internet”. If the first host can be reached only from other hosts directly connected to the same data network as the first host, then that data network is said to be a “private” network, or a “closed” network, or just an “intranet”.
Many modern business organizations and even individuals own private networks they use for their respective purposes. Although such private networks often are physically connected to public networks such that hosts in the private networks may reach hosts in the public networks, they continue to be private as long as the hosts in the private networks are not reachable by hosts in the public networks. This is illustrated by FIG. 1, which shows a Host A 11 that is connected to a private network 12 and a Host B 14 that is connected to a public network 13. The networks 12, 13 are connected, and the Host A is able to send data 15 to the Host B, as depicted by the solid line, but the Host B 14 is unable to send data 16 to the Host A 11, as depicted by the dashed line.
Like FIG. 1, workers in many modern organizations are not able to connect their respective hosts (i.e., Host B in FIG. 1) to hosts in their organizations' private networks (i.e., Host A in FIG. 1) for economic, physical, security, or other reasons. If such connections are needed, a Virtual Private Network (VPN) can be used. A VPN refers to the situation where two or more private networks physically interconnected by a public network appear to be a single private network (i.e., a “virtual” private network). Thus, a host outside one of the real private networks is allowed to access hosts inside that one of the real private networks as long as the host is connected to a real private network that is part of the virtual private network.
FIG. 2 depicts such a VPN. As in FIG. 1, the Host A 11 is connected to a first private network 12 and is able to send data 15 to the Host B 14 that is connected to a public network 13, and the Host B 14 is unable to send data 16 to the Host A 11. The Host A 11 is also able to send and receive data 18 to a Host C 17 that is connected to a second private network 21. In the same way, Host C 17 is able to send data 20 to Host B 14, but Host B 14 is unable to send data 19 to Host C 17. In the arrangement depicted in FIG. 2, the real private networks 12, 21 are part of a wider “virtual” private network.
One common way of implementing a VPN is by an Internet Protocol Security (IPSec) tunnel. IPSec is a network-layer protocol suite for sending and receiving internet protocol (IP) digital data packets, or blocks, by communicating devices (“peers”), such as routers, in a computer network. IPsec supports transport and tunnel encryption modes. In the transport mode, an IPSec device at the source, or sender, encrypts the data (payload) of each packet, but not the packet header, and in the tunnel mode, the sending IPSec device encrypts the header and the payload of each packet. At the destination, or receiver, of the packets, an IPSec device decrypts each packet. Thus, an IPSec tunnel is implemented by a tunneling protocol, i.e., a protocol that is able, in a transparent way, to carry other protocols inside it.
In a typical arrangement, one IPSec tunnel is established between every pair of real private networks that are part a VPN, but other arrangements, such as a star configuration, are also possible. This is illustrated by FIG. 3, in which an IPSec tunnel between the Host A 11 and Host C 17 is physically supported by a first IPSec device 303 that is connected to the private network 12 and a second IPSec device 306 that is connected to the private network 21. The IPSec device 303 receives a data packet 309 from the Host A 11, encapsulates it in a data packet 310 that is authenticated and/or encrypted using an agreed-on cryptographic suite, and then forwards the protected data packet 310 to the (remote) IPSec device 306. The IPSec device 306 performs the opposite operations, i.e., it removes the protection from the data packet 310 and extracts the encapsulated packet 309, which it then forwards to its destination, Host C 17.
It will be noticed from FIG. 3 that because hosts in the public network 13, e.g., Host B 14, have not agreed on the cryptographic suite with either IPSec device 303, 306, such hosts are unable to decipher the data packets in the “tunnel” between the private networks 11, 21. This in itself does not change the private or public condition of the networks involved, but in most cases it is convenient to allow hosts in a private network to access hosts in a public network. Thus, IPSec devices are able to detect when a data packet is addressed to a host in a real private network that is part of the VPN and when a data packet is addressed to a host in a public network, and to avoid protecting or tunneling the latter.
FIG. 4 depicts a VPN configured with the Host A 11 connected to the private network 12 that is connected through the IPSec device 303 to the public network 13. The Host B 14 is also connected to the public network 13, but through an IPSec device 406 contained in or associated with the Host B 14. This kind of VPN configuration can occur when an employee is outside all of the real private networks owned by an organization and has a connection to a public network as the only way to access the organization's network(s). The IPSec device 406 that is necessary to support the remote worker host's end of the IPSec tunnel is typically collocated with the remote worker's host as depicted in FIG. 4, and operates in a manner that corresponds to that of the device 306.
To establish an IPSec tunnel between two IPSec devices, a Security Association (SA) is created locally at each IPSec device. The SA is a container for the tunnel's characteristics, including the source and destination IP addresses, a tunnel identifier, cryptographic suite(s) to use for encryption and/or authentication, and keys to use with the suite(s). A SA can be set up manually, for example by having a network administrator configure each IPSec device, or automatically, for example by having the IPSec devices exchange messages using a protocol called Internet Key Exchange (IKE). The IKE protocol enables secure negotiation of cryptographic suites for encryption and/or authentication and secure exchange of the keys to be used. The IKE protocol also enables changing the keys dynamically during the life of a tunnel to further strengthen the security of the tunnel.
Implementing IPSec tunnels between the different real-private-network parts of a VPN is difficult. The administrator or administrators of the private networks need to configure an IPSec device for each respective real private network with an initial SA for each tunnel. When the IKE protocol is not used, all of the SA information has to be provided by the administrator (manual configuration); otherwise, only the source and destination network addresses and SA identifier need to be provided.
Configuring even just the source and destination network addresses at each IPSec device poses the problem that when one of those addresses changes, all of the IPSec devices that hold a tunnel to the IPSec device with the changed address need to be updated. As the number of IPSec tunnels in a VPN increases, the tunnel management burden increases as well. In a mesh configuration, the time complexity increases as ⊖(2n), which is to say, on the order of 2n, and in a star configuration, the burden increases as ⊖(n), which is to say linearly with n, where n is the number of tunnels.
The private network administrator or administrators also need to deploy and manage the keys used for encryption and/or authentication for each IPSec tunnel. Key delivery and management poses multiple security risks, since if even one key is compromised, an unauthorized party using the leaked key and a host in a public network might be able to decrypt and, even worse, authenticate packets exchanged with the private network(s). In the case illustrated by FIG. 4, the risk of key leakage is greatly increased. To tackle such risks, organizations burden their remote workers with “strong” key management processes, like smart cards for generating one-use passwords, “hard tokens”, etc.
Moreover, the very notion of an SA is eminently static, in that SAs need to be manually created in the IPSec devices at each end of a tunnel, at least to some extent. It is thus not possible to establish tunnels between devices when one device does not “know” the other (i.e., one peer does not have a pre-configured SA with the other peer's address). After a tunnel is established, the cryptographic suites used to encrypt and/or authenticate traffic through the tunnel cannot be changed without shutting down the tunnel and then re-establishing a tunnel with the new suites. In a VPN having one or more single-host private networks as in FIG. 4, it is usually not possible to send data packets to one of those remote hosts unless that host's IPSec device has already established a tunnel to a peer IPSec device. The reason is that the remote hosts often have addresses that are dynamically assigned on connection to the VPN, and so the target host's address is not known until it actually connects to the VPN.
Wireless and other communication networks are typically built according to specifications promulgated by standardization organizations, such as the Third Generation Partnership Project (3GPP). 3GPP specifies the GSM telecommunication system and its enhancements, e.g., General Packet Radio Service (GPRS) and Enhanced Data Rates for GSM Evolution (EDGE), the universal mobile telecommunications system (UMTS), and systems employing wideband code-division multiple access (WCDMA).
Such networks can now include an IP Multimedia Subsystem (IMS) that uses the Session Initiation Protocol (SIP) as its basic signaling mechanism. SIP is a mechanism for finding and routing control signals between endpoints, and the typical IMS architecture is a framework of network elements that employ various SIP routing devices to fulfill different roles regarding service triggering, authentication and authorization, media plane resource invocation, network interconnect, topology hiding, scalability, resilience, and other network properties. The IMS is integrated into existing mobile communication network infrastructures by relying on the home subscriber server (HSS), including the Home Location Register (HLR) to provide subscriber information, and the security identity module (SIM) card in a user equipment (UE) to assist in verifying the end-user, device, charging, media gateways, and signaling gateways.